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The  Presidio  of  Monterey  Field  Unit  of  the  Army  Research  Institute  (ARI) 
is  concerned  with  Improving  unit  collective  training  through  research  and 
development.  One  aspect  of  this  work  concerns  the  design  and  preparation  of 
Army  Training  and  Evaluation  Program  (ARTEP)  documents  by  Army  service  schools 
as  guides  to  unit  collective  training.  Research  in  this  area  is  conducted  by 
the  Collective  Training  Design  Team  under  the  sponsorship  of  the  proponent  for 
|  ARTEP  development  policy  and  procedures,  the  U.S.  Army  Training  Board  (ATB). 

! 

ARI  and  ATB  are  developing  a  Computer-aided  ARTEP  Production  System  (CAPS) 
in  cooperation  with  the  U.S.  Army  Infantry  School  (USAIS),  the  U.S.  Army  Armor 
School  (USAARMS),  the  U.S.  Army  Intelligence  Center  and  School  (USAICS),  and 
the  Army  Training  Support  Center-Information  Management  Office  (ATSC-IMO). 

!  This  report  provides  an  updated  version  of  the  CAPS  design  concept,  and  it 

|  defines  the  roles  of  CAPS  project  participants  in  the  upcoming  development  of  a 

i  working  CAPS  within  USAIS. 
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DEFINING  ROLES  IN  THE  DEVELOPMENT  OF  A 
COMPUTER-AIDED  ARTEP  PRODUCTION  SYSTEM  (CAPS) 


Introduction 

A.  The  Growing  Need  to  Automate  ARTEP  Production 

U.S.  Army  branch  service  schools  are  responsible  for  preparing  ARTEP 
documents  as  guides  to  unit  training.  The  preparation  of  an  ARTEP  is  a 
lengthy,  complex  task.  Drafting  an  ARTEP  requires  searching  for  appropriate 
reference  in  tactical  doctrine,  analyzing  mission/task  performance 
requirements,  and  writing/editing  voluminous  amounts  of  material  (i.e.,  the 
resulting  product  may,  in  certain  cases,  exceed  one  thousand  pages). 

The  workload  associated  with  the  preparation  of  ARTEPs  is  substantial  in 
terms  of  the  number  of  ARTEPs  to  be  prepared  by  each  school  and  in  terms  of 
the  amount  of  work  required  to  prepare  each  ARTEP.  Current  efforts  to 
modernize  the  force  have  increased  the  number  of  ARTEPs  produced  within 
certain  schools,  while  efforts  to  improve  ARTEPs  have  had  the  effect  of 
increasing  the  work  required  to  prepare  each  ARTEP. 

The  number  of  ARTEPs  to  be  produced  by  a  school  depends  on  the  number  of 
unit  types  for  which  that  school  is  responsible  for  preparing  ARTEPs,  and  it 
depends  on  the  frequency  with  which  each  ARTEP  must  be  revised.  Ongoing 
efforts  to  modernize  the  force  often  result  in  new  types  of  units  for  which 
schools  must  assume  responsibility.  Further,  force  modernization  through  the 
adoption  of  advanced  weapons,  vehicles  and  equipment  often  results  in  changes 
in  the  tactical  doctrine  for  existing  units,  and  these  changes  in  doctrine 
necessitate  revisions  of  ARTEPs. 

The  workload  associated  with  the  preparation  of  each  ARTEP  is  growing  in 
an  effort  to  more  effectively  meet  the  information  needs  of  ARTEP  users.  In 
the  past,  ARTEPs  provided  users  with  potential  training  requirements  by 
describing  unit  missions  and  subordinate  collective  tasks.  These  descriptions 
were  developed  through  the  process  of  Front-End  Analysis  (FEA).  The  new 
generation  of  improved  ARTEPs  provides  descriptive  unit  training  plans  called 
ARTEP  Mission  Training  Plans  (AMTPs)  and  Drills.  These  improvements  shift 
certain  complex  analyses  required  to  develop  unit  training  plans  from  the 
shoulder  of  the  ARTEP  user  to  that  of  the  ARTEP  developer.  That  is,  ARTEP 
developers  must  carefully  analyze  training-relevant  features  of  specific 
collective  tasks  and  use  the  results  of  these  analyses  to  develop  descriptive 
vnit  training  plans.  Figure  1.  illustrates  the  growth  of  the  ARTEP 
development  process  as  a  function  of  ARTEP  improvement. 

The  preparation  and  revision  of  ARTEP  products  is  presently  accomplished 
by  use  of  typewriters  and  stand-alone  word  processors.  The  ARTEP  development 
audit  trail  linking  tactical  doctrine  (e.g.,  "How  to  Fight"  manuals)  to  FEA  to 
ARTEP  documents  is  represented  by  a  lengthy,  complex  paper  trail.  Thus  there 
is  a  considerable  time  lag  between  the  point  when  the  need  to  prepa re/ revise 
an  ARTEP  is  recognized  and  the  point  when  a  finished  product  is  made 
available.  Automating  the  ARTEP  development  process  will  help  schools  to  be 
more  responsive  to  the  needs  of  ARTEP  users. 


New  Steps  in  ARTEP  Development 


Conduct 

Front-End  Analysis 


o  Define  Collective  Mission/Task 
Training  Requirements 

o  Define  Individual  Task 
Training  Requirements 


Identify  Chunks  of  Mission/Task 
Training  Requirements  to  be 
Addressed  by  the  Following 
Types  of  Exercises:  FTXS, 

STXS,  Drills 


Develop  FTXS,  STXS  and  Drills 

o  Detailed  T  &  EOs  and 
Drill  Standards 
o  Set-up  Directions 
o  Resource  Requirements 


Develop  Guidance  (Training 
Matrices)  for  Use  in 
Integrating  Exercises  into  Unit 
Training  Plans 


Figure  1.  Growth  of  the  ARTEP  Development  Process  as  a  Function  of  the  ARTEP 
Improvement  Effort. 
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B.  The  Importance  of  Standardized  Yet  Flexible  Application  of  Computer 
Technology  to  ARTEP  Development 

Haphazard  automation  is  potentially  a  serious  problem  resulting  in 
wasteful  duplication  of  effort  and/or  Inadequate  attempts  to  automate 
functions.  Army  Regulation  18-1,  Army  Automation  Management,  was  developed  to 
guide  the  application  of  automation  to  Army  needs.  Compliance  with  AR  18-1 
imposes  the  requirement  to  consider  the  functions  and  hardware /software 
specifications  of  other  automated  systems  with  which  the  system  under 
development  might  need  to  interface.  In  the  case  of  ARTEP  development,  there 
are  already  a  number  of  related  automated  systems  under  development  which  need 
to  be  considered  (see  Table  1.).  Attaining  compatibility  with  these  systems 
will  ensure  effective  transmission  of  information  among  schools  and 
integrating  centers,  and  it  will  provide  valuable  information  about  how  ARTEP 
products  are  used  by  operational  units. 

For  two  reasons,  it  is  also  critical  that  automation  be  applied  to  ARTEP 
development  in  a  flexible  fashion.  First,  the  ARTEP  development  process 
differs  among  the  various  schools.  Second,  the  ARTEP  document  was  intended  to 
be  evolutionary  in  nature,  and  it  has  proven  to  be  evolutionary  in  nature. 
Effective  application  of  computer  technology  to  ARTEP  development  requires  a 
standardized  system  concept  which  can  accommodate  differences  among  schools 
and  continued  evolution  of  the  ARTEP  document. 

C.  The  Computer-aided  ARTEP  Production  System  (CAPS)  Project 

The  U.S.  Army  is  preparing  to  apply  computer  technology  to  the  job  of 
preparation  of  ARTEP  documents  through  the  development  of  a  Computer-Aided 
ARTEP  Production  System  (CAPS).  Participants  in  this  effort  include  the  U.S. 
Army  Training  Board  (ATB) ,  the  U.S.  Army  Infantry  School  (USAIS),  the  U.S. 

Array  Armor  School  (USAARMS),  the  U.S.  Army  Intelligence  Center  and  School 
(USAICS),  the  U.S.  Army  Training  Support  Center-Information  Management  Office 
(ATSC-IMO)  and  the  U.S.  Army  Research  Institute  (ARI). 

The  CAPS  project  is  divided  into  three  phases.  Phase  I  is  now  complete. 

It  involved  defining  the  CAPS  concept  to  an  extent  whj^h  provided  valid 
estimates  of  CAPS  hardware  and  software  requirements.  In  brief,  the  CAPS 
design  concept  calls  for  applying  commercially  available  software  known  as  a 
Relational  Database  Management  System  (RDBMS)  to  the  ARTEP  development 
process.  Such  a  system  is  expected  to  be  flexible  enough  to  accommodate 
differences  among  schools,  because  each  school  would  have  control  over  the 
information  to  be  placed  in  the  database,  as  well  as  having  control  over  how 
this  information  is  applied.  Standardization  over  the  application  of  computer 
technology  to  ARTEP  development  is  gained  by  reducing  the  hardware  and  RDBMS 
options  to  those  compatible  with  related  systems  under  development  within  the 
Army. 


AR  18-1  will  be  replaced  by  AR  25-5,  however,  the  automation  concerns 
^scribed  in  this  report  are  not  influenced  by  this  replacement. 

Bloedorn,  Crooks,  Merrill,  Saal,  Meliza  and  Kahn.  Concept  Study  of  the 
Computer-aided  ARTEP  Production  System  (CAPS).  ARI  Research  Report  1403, 
July,  1985. 


Table  1 . 


I  Selected  Systems  with  Which  CAPS  Must  Interface 

i 

i 

I  TRADOC  COWAND  MANAGEMENT  INFORMATION  SYSTEM  (TCMIS)  Controls  exchange  of 

Information  among  TRADOC  schools/agencies.  Subsumes  a  wide  range  of  automated 
systems  (including  CAPS). 


DEFENSE  DATA  NETWORK  (DDN)  Transmits  data  between/among  TRADOC  installations. 


ARMY  INTEGRATED  PUBLISHING  AND  PRINTING  SERVICE  (AIPPS)  Responsible  for  mass 
printing  of  test  and  final  ARTEP  products. 

i  i 

|  INTEGRATED  TRAINING  MANAGEMENT  SYSTEM  (1TMS)  Unit  automated  training 

management  system. 


i 

i 

i 


! 
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The  second  phase  of  the  CAPS  project  involves  developing  a  working  CAPS 
within  USA1S.  During  this  phase,  the  working  CAPS  will  pass  through  the 
entire  Army  Automation  Life  Cycle,  summarized  in  Table  2.  Information  gained 
from  the  development  of  the  working  CAPS  will  carry  the  TRADOC-wide  CAPS  from 
the  "Mission  Analysis  Project  Initiation"  phase  through  the  "Concept 
Development"  phase  of  the  life  cycle.  In  addition,  information  gained  through 
carefully  defined  reviews  of  the  working  CAPS  by  USAARMS  and  USAICS  should 
carry  the  TRADOC-wide  CAPS  through  the  "Definition  and  Design,"  and  "System 
Development"  phases,  and  hasten  TRADOC-wide  Implementation  within  the 
"Development  and  Operations"  phase. 

Phase  III  involves  refining  CAPS  during  and  after  TRADOC-wide 
implementation.  Many  refinements  will,  in  fact,  be  made  by  particular  schools 
to  ensure  that  the  CAPS  effectively  meets  their  specific  needs.  Other 
refinements  will  be  made  to  take  advantage  of  (1)  the  wealth  of  information 
available  from  related  automated  systems  and  (2)  improvements  in  hardware  and 
software. 

The  project  management  information  developed  by  the  CAPS  Project  will  be 
used  by  the  ATSC  Information  Management  Office  (IMO),  the  Project  Manager  for 
the  TRADOC  Command  Management  Information  System  (TCMIS)  Training  Module.  As 
presently  conceived,  CAPS  will  be  an  integral  part  of  the  TCMIS  Training 
Module  and  utilize  TCMIS  hardware. 

D.  Purpose  and  Format  of  Document 

User  involvement  in  the  development  of  a  product,  such  as  a  CAPS,  helps  to 
ensure  the  product  will  be  successfully  implemented.  In  cases  where  the 
product  to  be  developed  is  an  automated  system,  it  is  also  important  to 
coordinate  with  developers  of  related  automated  systems.  However,  an  Increase 
in  the  number  of  organizations  involved  in  product  development  can  delay  or 
even  abort  product  development.  The  solution  to  this  apparent  dilemma  is  to 
carefully  define  roles  of  participating  organizations  as  early  as  possible. 

The  purpose  of  this  document  is  to  help  prepare  project  participants  for 
their  upcoming  roles  in  the  development  of  a  working  CAPS  within  USAIS  and  to 
provide  an  updated  version  of  the  CAPS  design  concept  which  reflects  (1) 
reductions  in  CAPS  hardware/software  options  to  support  compatibility  with 
other  automated  systems,  (2)  modifications  of  hardware /software  options  to 
take  advantage  of  recent  advances  in  computer  technology,  and  (3)  recent  work 
on  refining  the  ARTEP  development  process  to  be  assisted  by  automation. 


Table  2 


Overview  of  Che  A ray  Autonation  Life  Cycle 


Phase _ _ 

Mission  Analysis/Project 
Initiation 

Concept  Development 


Definition  and  Design 


System  Development 
Deployment  and  Operation 


Description _ 

Describe  the  Army  mission  functions 
to  which  automation  may  be  applied. 

Analyze  and  evaluate  alternative 
methods  to  accomplish  functions 
identified  In  previous  phases. 

Fully  define  functional  requirements 
and  design  operable  automated 
system. 

Implement  and  test  automated  system. 

Install  and  operate  system  at  all 
approved  locations.  Improve  and 
refine  system  if  necessary  and 
feasible. 
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The  CAPS  Design  Concept 


A*  CAPS  Hardware 

Figure  2.  illustrates  the  major  hardware  components  of  the  CAPS 
concept.  Each  of  these  components  is  discussed  below  in  brief  detail. 

1.  Central  Minicomputer 

The  central  minicomputer  will  contain  that  part  of  the  ARTEP  development 
database  which  needs  to  be  tightly  controlled  because  its  contents  are  shared 
among  the  various  organizations  Involved  in  ARTEP  development.  This  database 
Includes  "finished  products"  of  the  work  of  doctrine  developers,  task  analysts 
and  ARTEP  writers.  The  contents  of  the  database  are  shared  in  that  the 
products  of  the  work  of  one  individual /group  serve  as  input  for  the  work  of 
other  individuals/groups. 

A  wide  range  of  minicomputers  has  the  potential  to  meet  the  memory 
requirements  specified  in  the  concept  study.  To  ensure  compatibility  with  the 
TCM1S,  Training  Module  it  was  decided  that  the  options  for  the  CAPS 
minicomputer  should  be  reduced  to  VAX  11/750  "look  alikes".  Most  Army  schools 
are  already  familiar  with  the  VAX  11/750  because  it  is  the  Army  Instructional 
Management  System  (AIMS)  computer. 

To  effectively  serve  multiple  ARTEP  development  functions  and  to  store  the 
large  number  of  documents  involved  in  the  ARTEP  development  process,  the  CAPS 
concept  requires  expanding  the  random  access  memorary  (RAM)  of  the  basic  VAX 
11/750  by  sixf old.  The  RAM  of  the  CAPS  is  thus  much  greater  than  that  of  the 
initial  AIMS  (i.e. ,  the  AIMS  is  scheduled  for  a  near-term  upgrading  of  RAM). 
The  large  RAM  of  the  CAPS  VAX  11/750,  combined  with  the  use  of  "smart"  work 
stations  capable  of  performing  information  processing  activities,  should  help 
to  avoid  the  long  delays  sometimes  encountered  when  a  system  has  multiple 
users. 


2.  Work  Station 

Personal  computers  (PCs)  linked  to  the  central  minicomputer  will  directly 
support  the  work  of  individual  task  analysts  and  ARTEP  writers.  The  PC 
database  will  contain  (l)  copies  of  finished  products  serving  as  input  to  a 
particular  job,  (2)  working  notes,  and  (3)  draft  products.  The  use  of  PCs,  as 
opposed  to  "dumb  terminals"  will  shift  much  of  the  processing  load  from  the 
minicomputer  to  work  stations. 

The  PC  to  be  used  for  CAPS  "smart"  work  stations  must  meet  the 
requirements  described  below. 

o  The  PC  must  be  able  to  communicate  with  the  VAX  11/750  to  allow 
transfer  of  files  between  the  work  station  and  the  central 
minicomputer.  Quite  simply,  a  PC  and  a  minicomputer  like  the  VAX 
11/750  t ransmit / recei ve  data  in  ways  which  are  incompatible. 
Therefore,  a  hardware /sof tware  solution  must  have  been  developed 
which  allows  the  PC  selected  to  emulate  a  "dumb"  terminal  for  the  VAX 
11/750. 
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Figure  2.  Major  Hardware  Components  of  a  CAPS 
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High  resolution  graphics  monitors  must  be  available  for  use  with  the 
selected  PC.  This  requirement  is  due  to  the  fact  that  approximately 
50  percent  of  the  content  of  AMTP/Drill  documents  is  in  the  form  of 
figures  and  tables. 

o  Software  necessary  for  the  PC  to  support  graphics,  word  processing 
and  analytical  functions  must  be  available. 

A  wide  range  of  PCs  appears  to  meet  the  above  specifications.  However, 
the  ideal  PC  would  be  the  one  selected  to  replace  the  "dumb"  terminal 
currently  employed  by  the  AIKS  (i.e. ,  as  part  of  the  TCMIS-Training  Module). 
Unfortunately,  this  PC  requires  a  software  solution  to  allow  full 
conaunication  between  the  PC  and  the  minicomputer.  While  the  necessry 
solution  is  under  development,  and  the  solution  will  undoubtedly  be  available 
prior  to  TRADOC-wide  implementation  of  CAPS,  the  solution  may  not  be  available 
in  time  to  allow  this  PC  to  be  used  for  the  working  CAPS  at  USA1S.  At  any 
rate,  the  PC  for  the  working  CAPS  will  be  selected  in  a  way  which  ensures  that 
the  results  of  this  effort  can  be  ported  to  TCMIS-Training  Module  hardware  and 
software.  Selection  of  the  PCs  will  be  delayed  until  the  functional 
requirements  for  a  CAPS  are  finalized /up dated  during  the  first  task  involved 
in  developing  a  working  CAPS. 

3.  High-speed  Laser  Printers 

Quality  printing  of  graphics  requires  the  use  of  high-speed  laser 
printers.  Such  printers  also  offer  the  benefit  of  a  quick  turn  around  time 
when  draft  ARTEP  products  are  prepared  for  staffing.  The  cost  of  these 
printers  vary  considerably.  Laser  printers  meeting  high  durability 
specifications  (in  terms  of  printing  loads)  cost  much  more  (i.e.,  as  much  as 
twenty  times  more)  than  newer  printers  meeting  moderate  specifications.  It 
must  also  be  considered  that  the  CAPS  printers  will  not  be  used  in  mass 
producing  ARTEP  products  for  Army-wide  distributing,  because  such  heavy 
printing  loads  are  a  function  of  the  Army  Integrated  Printing  and  Publication 
System.  Therefore,  given  the  comparatively  small  printing  load  expected  for 
CAPS,  printers  meeting  moderate  durability  specifications  appear  to  be 
adequate. 


4.  Optical  Character  Reader 

The  concept  study  for  a  CAPS  prototype  also  produced  an  initial  plan  for 
effecting  the  transition  to  automated  ARTEP  production.  A  key  element  of  this 
transition  is  the  transfer  of  all  the  documents  pertinent  to  ARTEP  production 
to  the  CAPS  database.  A  powerful  tool  suggested  for  use  in  accomplishing  this 
task  is  the  Optical  Character  Reader  (OCR).  An  OCR  removes  the  need  to  type 
thousands  of  pages  of  material  into  the  CAPS. 

B.  Relational  Database  Management  System 

The  CAPS  concept  calls  for  using  the  INGRES  Relational  Database  Management 
System  (RDBMS)  to  support  ARTEP  development,  rather  than  developing  new 
software.  That  is,  commercially  available  software  which  has  already  been 
successfully  applied  to  help  automate  a  number  of  jobs  will  be  applied  to 
ARTEP  development. 


vv.v.v. 


The  INGRES  was  selected  over  other  relational  database  management  systems 
to.  In  part,  ensure  compatibility  between  CAPS  and  the  TCMIS-Training 
Module.  Brief  descriptions  of  a  RDBMS  and  potential  applications  of  a  RDBMS 
to  ARTEP  development  are  provided  below.  Finally,  a  brief  "walk-through"  of 
the  use  of  a  RDBMS  in  preparing  AMTP/Drill  documents  is  provided. 

1.  Description  of  a  RDBMS 

Conceptually,  a  RDBMS  stores  information  in  a  tabular  format.  A  RDBMS  is 
"user-friendly"  because  one-line  commands  can  be  used  to  (a)  load  information 
into  tables  (b)  revise/update  information  and  (c)  reorganize  information 
within  and  across  tables  to  meet  information  needs  of  database  users. 

Figure  3.  illustrates  portions  of  two  hypothetical  RDBMS  tables.  Each 
table  has  a  name  and  is  organized  so  that  column  2  and  beyond  provide 
Information  about  the  people,  objects  or  events  listed  in  column  1.  For 
example,  the  table  called  "education"  contains  information  about  the  personnel 
listed  in  column  1  (e.g. ,  rank,  highest  degree  received,  undergraduate  and 
graduate  schools  attended).  A  file  containing  such  information  on  thousands 
of  individuals  might  be  inserted  into  a  RDBMS  table  using  a  single  one-line 
command. 

Certain  benefits  gained  by  having  information  in  a  tabular  format  can  be 
illustrated  by  again  using  Figure  3.  First,  a  one-line  command  might  be  used 
to  provide  a  list  of  individuals  meeting  either  a  specific  criterlum  (e.g., 
having  an  MS  degree)  or  combination  of  criteria  (i. e.,  having  an  MS  degree 
from  Yale).  Second,  the  RDBMS  can  be  used  to  answer  questions  which  involve 
analyzing  Information  in  more  than  one  table.  For  example,  the  table 
"college"  in  Figure  3.  contains  information  about  specific  colleges  (i.e. , 
whether  the  schools  has  a  ROTC  program,  approximate  number  of  students).  The 
information  within  the  "education"  and  "college"  tables  can  be  selected  out 
and  reorganized,  in  response  to  a  one-line  command,  to  provide  a  list  of  the 
personnel  which  have  received  degrees  from  schools  having  ROTC  programs. 

The  application  of  a  RDBMS  to  particular  jobs  involves  deciding  what 
information  is  to  be  stored  in  the  database,  and  it  involves  deciding  how  to 
organize  this  information  into  tables.  The  manner  in  which  information  is 
arranged  into  tables  is  important,  in  part,  to  ensure  that  analyses  can  be 
performed  across  tables  where  necessary. 

2.  Potential  Application  of  a  RDBMS  to  ARTEP  Development 

A  greater  appreciation  of  the  application  of  a  RDBMS  to  ARTEP  development 
can  be  gained  by  considering  the  types  of  information  which  might  be  contained 
in  a  CAPS  database.  Figure  4.  illustrates  a  portion  of  a  CAPS-re levant  table 
which  provides  two  types  of  information  about  collective  tasks  (i.e.,  the 
references  from  tactical  doctrine  which  support  each  task  and  the  name  of  the 
STXs  in  which  each  task  is  embedded).  The  utility  of  the  table  to  ARTEP 
developers  can  be  illustrated  by  considering  that  a  one-line  command  could  be 
used  to  provide  a  list  of  all  of  the  collective  tasks  and  STXs  supported  by  a 
specific  reference  from  tactical  doctrine. 

The  specific  information  to  be  included  in  a  CAPS  database,  as  well  as  the 
manner  in  which  this  information  will  be  organized  into  tables,  will  be 
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ARTFT  development 


determined  in  the  course  of  devloping  a  CAPS  within  USAIS.  In  addition,  it 
must  be  considered  that  a  particular  school  would  have  the  flexibility  to 
Include  additional  types  of  information  within  a  CAPS  database. 

C.  CAPS  "Walk-Through" 

The  description  of  CAPS  hardware  components  and  RDBMS  features,  provided 
above,  set  the  stage  for  a  "walk-through"  of  the  application  of  a  CAPS  to  the 
development  and  revision  of  AMTP/Drlll  documents  This  walk-through  will  be 
conducted  using  Figure  5.  as  an  aid.  This  figure  Indicates  the  major 
components  of  the  database  and  the  sequence  in  which  the  components  are  loaded 
into  the  database.  A  portion  of  these  components  will  be  handed-off  to 
schools,  and  the  remainder  will  be  developed  by  schools  during  the  AMTP/Drlll 
development  process. 

The  component  to  be  handed-off  to  schools  contains  the  POI  for  using  the 
CAPS  to  develop  AMTP/Drlll  documents.  This  POI  defines  the  decisions  to  be 
made  and  products  to  be  produced  within  each  step  of  the  AMTP/Drill 
development  process,  provides  decision  aids  (rules  of  thumb  and  examples  of 
the  application  of  these  rules)  to  support  each  of  the  judgments  to  be  made 
during  the  process,  tells  the  user  how  to  reorganize  the  information  within 
the  database  to  meet  specific  information  needs  (standardized  one-line 
commands),  and  provides  Instructions  for  loading  existing  and  newly  developed 
information  and  products  into  the  database. 

The  first  component  of  the  database  to  be  loaded  at  a  particular  school 
will  be  a  description  of  the  AMTP/Drill  development  workflow  within  that 
school.  This  component  serves  at  least  two  major  functions.  First,  it  makes 
it  possible  to  link  specific  duty  postions  to  the  appropriate  portion  of  the 
POI.  Second,  It  identifies  the  "owners"  of  the  tables  to  be  produced  during 
the  AMTP/Drill  development  process  who  have  authority  to  add  to  or  modify 
these  tables  (e.g. ,  who  has  the  authority  to  control  the  contents  of  the 
tables  containing  tactical  doctrine). 

The  next  component  of  the  database  to  be  loaded  will  be  the  source 
materials  used  in  conducting  a  FEA  (e.g.,  "How  to  Fight"  Manuals,  Battlefield 
Development  Plans).  The  loading  of  these  materials  will  be  accomplished  with 
the  aid  of  an  OCR  to  avoid  excessive  typing  requirements. 

Once  the  system  has  been  loaded  with  the  three  database  components 
described  above,  it  should  be  set  to  guide  users  in  conducting  a  FEA.  The 
user  will  be  instructed  in  using  the  RDBMS  to  rapidly  reorganize  the  contents 
of  FEA  source  materials  to  facilitate  the  analysis  of  these  materials.  For 
example,  the  system  might  assist  the  user  in  identifying  the  tactical 
references  appropriate  to  a  specific  collective  task  by  locating  all  doctrinal 
references  (FM,  page  and  paragraph  numbers)  containing  a  key  word  or  phrase 
(e.g.,  overwatch  position,  surveil1  nee).  The  user  might  then  call  up  the 
text  of  these  references  on  his/her  terminal  to  determine  the  true 
applicability  of  each  potential  reference  to  the  collective  task.  The 
products  of  the  FEA  will  be  loaded  into  the  database,  and  they  are  likely  to 
include  the  following:  the  name  of  potential  mission  and  collective  task 
training  requirements;  a  description  of  what  a  unit  should  do/accomplish  in 
performing  each  mission/task;  resource  requirements  for  performing  each  task; 
doctrinal  references  for  mission  tasks.  Note  that  in  performing  a  FEA,  part 

I  ! 


OOGO 

Q_>- 

UJOO 


Od 

Q_ 


£UJ 

Ooc 

<_>«£ 


0<v:u 

t —  I —  Vi 


s<uj5> 


Figure  5.  Major  components  of  a  CAPS  database  and  transition  to 
automated  ARTEP  production 


of  the  fifth  component  of  the  database  will  also  be  produced  (the  template 
linking  tactical  doctrine  to  specific  missions/tasks). 

After  a  traditionally  established  FEA  has  been  conducted,  the  CAPS  should 
guide  users  in  the  selection  of  slices  of  battle  to  be  addressed  by  Drills, 
STXs  and  FTXs.  The  process  of  selecting  Drills  and  STXs  is  an  especially 
critical  and  complex  stage  of  the  AMTP/Drill  development  process  requiring 
complex  judgments.  Therefore,  the  POI  portion  of  the  database  is  likely  to 
provide  considerable  decision  aids  to  support  this  phase  of  ARTEP 
development.  In  addition,  the  POI  should  provide  instructions  for  analyzing 
the  FEA  and  tactical  doctrine  portions  of  the  database  to  provide  information 
which  facilitates  this  phase.  For  example,  an  important  part  of  the  selection 
process  for  both  Drills  and  STXs  is  the  comparison  of  training  requirements 
across  collective  tasks  to  identify  duplications  in  subtasks,  tasks  or 
sequences  of  tasks.  Information  about  collective  tasks,  recorded  during  FEA, 
should  help  CAPS  users  to  identify  groups  of  collective  tasks  which  warrant 
comparison  with  each  other  (e.g.,  tasks  likely  to  have  overlapping  training 
requirements  would  tend  to:  be  supported  by  the  same  doctrinal  references, 
serve  the  same  unit  functions,  and  have  similar  task  steps). 

In  the  course  of  selecting  Drills/STXs/FTXs,  the  CAPS  user  will  complete 
the  loading  of  the  fifth  component  of  the  database  by  linking  training 
exercises  to  each  other  (e.g.,  identifying  drill  prerequisites  for  specific 
STXs)  and  linking  exercises  to  specific  missions  and  tasks.  In  effect,  the 
fifth  component  of  the  database  should  serve  to  organize  the  AMTP/Drill  audit 
trail  to  support  subsequent  revisions  in  AMTP/Drill  documents.  For  example, 
the  fifth  component  should  make  it  possible  to  rapidly  identify  all  FEA 
products,  training  exercises  and  training  matrices  requiring  revision  as  a 
result  of  a  change  in  tactical  doctrine. 

The  sixth  and  final  component  of  the  CAPS  database  is  loaded  during  the 
preparation  of  AMTP/Drill  documents.  Once  again,  the  embedded  POI  should 
assist  the  user  in  analyzing  Information  within  the  database  to  develop 
Drills,  STXs  and  training  matrices.  In  fact,  the  contents  of  the  training 
matrices  should  already  be  embedded  in  the  fifth  component  and  need  only  be 
extracted  in  the  required  format. 


Tasks  in  Che  Developaent  of  a  Working  CAPS  Prototype /Roles  of  Participants 

The  effort  described  in  this  chapter  includes  the  design,  implementation 
and  testing  of  a  working  CAPS  within  USAIS,  and  it  includes  assessment  of  the 
applicability  of  the  prototype  design  features  to  schools  other  than  USAIS. 
Eight  major  tasks  are  addressed  during  the  development  of  a  CAPS  within 
USAIS.  Most  of  these  tasks  will  result  in  draft  products  which  can  be 
reviewed  by  USAARMS  and  USAICS  to  evaluate  the  applicability  of  the  product  to 
their  particular  situation.  Certain  feedback  obtained  from  service  schools 
may  Influence  the  prototype,  while  other  feedback  will  be  considered  in  the 
TRADOC-wide  implementation  of  CAPS. 

In  reviewing  these  reports,  schools  should  be  aware  that  report  formats 
are  not  an  issue  because  the  formats  of  the  various  reports  are  largely 
specified  within  DoD  and  DA  regulations.  These  formats  were  developed  to 
ensure  that  the  Information  contained  in  the  reports  can  be  easily  Interpreted 
by  Individuals  who  are  not  computer  professionals.  The  documents  which  define 
the  format  of  these  reports  are  as  follows: 

DoD  Standard  7935 
Army  Technical  Bulletin  18-103 
Army  Technical  Bulletin  18-111 
DoD  5000. 12-M,  and 
Army  Regulation  18-12 

The  eight  tasks  to  be  accomplished  during  the  development  of  a  CAPS  are 
described  below.  Each  description  provides  an  explanation  of  the  task 
objective  and  a  discussion  of  the  roles  of  the  various  participants  in 
reviewing  task  products.  These  discussions  attempt  to  define  the  types  of 
issues  addressed  in  regard  to  each  task  product.  Appendix  A  provides  a  brief 
summary  of  the  development  process. 

It  is  important  to  consider  that  the  CAPS  prototype  development  tasks  are 
not  necessarily  listed  in  the  exact  chronological  sequence  in  which  they  will 
be  performed.  The  task  sequence  will  not  be  finalized  until  a  contract  has 
been  awarded  for  the  development  of  a  working  CAPS. 

A.  Refine/Finalize  CAPS  Functional  Requirements 

CAPS  functional  requirements  were  defined  during  the  previous  concept 
study  to  an  extent  which  allowed  development  of  a  CAPS  design  concept  and 
identification  of  hardware/software  requirements  for  a  prototype.  Prior  to 
designing  a  CAPS  database  (deciding  what  information  to  include  in  a  CAPS 
database  and  how  to  arrange  this  information  into  tables),  it  is  necessary  to 
check  the  current  accuracy  of  the  functional  requirements  and  to  specify 
certain  functional  requirements  in  greater  detail. 

Before  describing  specific  types  of  functional  requirement  issues  likely 
to  arise  during  the  performance  of  this  task  it  is  important  to  consider  that 
the  FEA  and  AMTP/Drill  development  processes  (to  be  assisted  by  CAPS)  are 
under  development.  Based  upon  lessons  learned  during  the  development  of 
prototype  AMTP/Drill  products  by  service  schools,  efforts  are  being  made  to 
incorporate  a  certain  degree  of  "how  to"  guidance  into  TRADOC  Reg  310-2  (Test- 
Revised)  and  TRADOC  Reg  350-7.  Similarly,  guidance  for  conducting  a  FEA 


(TRADOC  PAM  310-8)  is  currently  under  revision.  Consideration  of  new  guidance 
documents  will  undoubtedly  influence  CAPS  functional  requirements.  In 
addition,  the  potential  for  applying  computer  technology  to  the  AMTP/Orill 
development  process  may  in  itself  make  it  advisable  to  modify  the  ATMP/Drill 
development  process.  For  example,  modification  of  the  sequence  in  which 
certain  ARTEP  development  tasks  are  performed  may  be  necessary  to  captialize 
on  the  potential  benefits  of  automation. 

Due  to  the  experimental  nature  of  the  AMTP/Drill  preparation  process, 
draft  CAPS  functional  requirements  will  be  prepared  for  review  by  service 
schools.  Draft  functional  requirements  will  be  developed  by  ATB,  ARI  and  the 
contractor.  These  requirements  will  reflect  consideration  of  (1)  guidance 
documents  for  conducting  a  FEA  and  preparing  AMTP/Drill  documents  and  (2)  the 
ARTEP  development  process  within  USAIS. 

In  their  review  of  the  draft  functional  requirements  document,  all 
participants  will  be  asked  to  answer  two  broad  questions.  First,  are  there 
ARTEP  development  jobs  which  are  not  addressed  (or  not  adequately  addressed) 
by  the  draft  functional  requirements?  Second,  do  the  functional  requirements 
appear  to  address  problems  encountered  in  preparing  prototype  AMTP  and  Drill 
documents  (e.g. ,  selecting  "mission-oriented"  chunks  of  battle  to  be  addressed 
by  STXs ) ? 

Schools  will  also  be  asked  to  respond  to  more  specific  questions  about  the 
functional  requirements  as  illustrated  below. 

o  To  what  level  of  detail  should  references  to  tactical  doctrine  be 

recorded  in  the  database  (e.g.,  FM  and  chapter  number  j>r  FW  and  page 
number  or_  FM,  page  and  paragraph  number)? 

o  What  types  of  FEA  source  materials  need  to  be  contained  in  the  CAPS 
database?  For  example,  many  schools  survey  units  regarding  the 
"criticality"  of  missions  and  tasks.  Based  upon  estimates  of  the 
utility  of  past  surveys,  schools  may  or  may  not  want  to  include  the 
results  of  such  surveys  in  the  database. 

The  results  of  reviews  by  USAARMS  and  USA1CS  will  be  used  in  one  of  two 
ways.  The  results  may  influence  the  functional  requirements  of  the  working 
CAPS  (i.e. ,  feedback  from  USAARMS  and  USAICS  might  include  innovative  ideas 
for  improving  the  ef f ectiveness/ ef f iciency  of  the  AMTP/Drill  development 
process),  or  they  may  serve  to  document  functional  requirements  which  need  to 
be  addressed  during  TRADOC-wide  CAPS  implementation.  The  decision  about 
whether  to  incorporate  the  feedback  into  the  working  CAPS  will  be  made  by  ATB, 
ARI  and  USAIS. 

It  is  expected  that,  in  most  cases,  modifying  the  CAPS  to  accommodate  the 
requirements  of  a  particular  school  will  merely  involve  expanding  the  database 
to  include  additional  tables.  However,  in  cases  where  a  simple  expansion  of 
the  database  is  not  sufficient  to  accommodate  the  needs  of  particular  schools, 
it  is  critical  that  this  fact  be  documented  for  use  by  ATSC-IMO  as  soon  as 
possible. 
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B.  Prepare  Organization,  Management  and  Operating  Procedures  for  a  CAPS 

Three  documents  will  be  prepared  by  the  contractor  which  combine  to  define 
the  roles  and  responsibilities  of  all  CAPS  managers,  supervisors,  users, 
operators  and  maintainers.  Some  of  the  questions  to  be  addressed  by  these 
documents  are  listed  below. 

o  How  will  table  "owners"  (individuals  with  the  authority  to  create  and 
change  the  content  of  specific  tables)  be  designated? 

o  How  will  information  be  protected  from  accidental  loss? 

o  What  will  be  the  specific  job  responsibilities  of  school  computer 
personnel? 

These  procedural  manuals  will  be  developed  by  considering  CAPS  functional 
requirements,  characteristics  of  CAPS  hardware/software,  and  the  manner  in 
which  USAIS  is  task  organized  to  accomplish  the  ARTEP  development  process. 
Therefore,  it  will  be  necessary  for  the  contractor  to  study  the  current  ARTEP 
development  process  within  USAIS  to  define  specific  ARTEP  development  jobs  in 
terms  of  inputs,  outputs  and  responsible  parties. 

It  is  expected  that  USAIS  and  USAARMS  will  have  considerable  experience  to 
draw  upon  in  reviewing  these  documents.  Schools  on  TRADOC  installations 
already  have  a  VAX  11/750  computer  as  part  of  the  Army  Instructional 
Management  System  (AIMS),  and  these  schools  are  currently  receiving  the  INGRES 
RDBMS  for  use  on  the  AIMS  computer.  Thus  school  computer  personnel  should 
have  considerable  experience  with  the  INGRES  and  VAX  11/750  prior  to  receiving 
the  CAPS  documents. 

Perhaps  the  key  concern  of  ARTEP  developers  in  reviewing  these  documents 
will  be  to  decide  if  the  procedures  are  compatible  with  the  way  their  school 
is  task  organized  to  accomplish  the  ARTEP  development  process.  In  addition, 
schools  will  want  to  determine  how  well  these  procedures  seem  to  fit  work 
schedules  (e.g. ,  must  school  computer  personnel  be  on  hand  if  it  becomes 
necessary  for  ARTEP  developers  to  work  late  at  night  to  meet  a  short  term 
suspense  date?). 

Two  types  of  feedback  might  be  expected  from  schools  at  this  point. 

First,  schools  may  report  inconsistencies  between  CAPS  procedures  and  school 
procedures.  Inconsistencies  which  apply  to  USAIS  will  be  immediately 
addressed  by  CAPS  developers.  Inconsistencies  which  apply  to  USAARMS  and/or 
USAICS  will  be  documented  for  the  attention  of  ATSC-IMO.  Second,  schools  may 
raise  questions  about  procedures  which  are  inadequately  described  in  the  draft 
CAPS  plans  and  require  the  inmediate  attention  CAPS  developers. 

C.  Design  CAPS  Database 

The  task  of  designing  a  CAPS  database  will  be  performed  by  the 
contractor.  The  objective  of  this  task  is  to  decide  what  types  of  information 
are  to  be  contained  within  each  table  and  table  column  of  a  CAPS  database. 

The  database  must  be  designed  to  address  the  CAPS  functional  requirements 
identified  in  the  first  task  of  prototype  de ve 1 opment .  For  example,  if  the 
functional  requirements  specify  that  the  system  should  illow  users  to  quickly 
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identify  the  specific  paragraphs  from  FMs  which  apply  to  a  particular  STX, 
then  such  information  must  be  addressed  by  database  designs. 
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Designing  a  CAPS  database  is  an  especially  critical  step  in  CAPS 
development.  If  the  database  is  effectively  designed,  then  it  should  be 
relatively  easy  to  apply  a  RDBMS  to  ARTEP  developments.  That  is,  very  simple 
commands  could  be  used  to  select  and  reorganize  information  in  the  database. 

If  the  database  is  not  well  designed,  then  very  complex,  lengthy  commands  may 
be  required  to  gain  information  from  the  database  or  certain  Information  in 
the  database  may  be  virtually  Inaccessible  to  database  users.  In  this  case  it 
may  be  necessary  to  develop  software  to  guide  CAPS  users  in  applying  a  RDBMS 
to  ARTEP  development.  Such  software  development  would  be  costly,  and  it  might 
reduce  the  flexibility  of  a  CAPS  to  accommodate  differences  among  schools. 

The  job  of  designing  a  database  for  a  CAPS  prototype  is  relatively  complex 
and  requires  considerable  experience  in  RDBMS  database  design  (i.e., 
particularly  in  regard  to  using  a  RDBMS  to  support  document  preparation). 

Much  of  the  Information  to  be  included  in  a  CAPS  database  is  in  the  form  of 
lists  and  text.  Deciding  how  to  incorporate  these  types  of  information  in  a 
RDBMS  requires  either  directly  relevant  experience  or  experimentation  with 
innovative  applications  of  a  RDBMS.  Once  these  problems  have  been  addressed 
in  prototype  development  (e.g.,  incorporating  text  from  FMs  into  the 
database),  the  solutions  can  also  be  applied  to  similar  problems  in  future 
expansions  of  the  CAPS  database  (e.g.,  including  additional  types  of  text  in 
the  database). 

The  report  produced  during  this  task  will  provide  schools  with  their  first 
detailed  view  of  the  contents  and  organization  of  a  CAPS  database.  Combined 
with  information  about  how  to  select  and  reorganize  information  in  the 
database  to  meet  various  information  needs  (to  be  prepared  in  the  subsequent 
CAPS  development  task),  it  will  also  provide  a  detailed  picture  of  how  a  RDBMS 
can  support  specific  ARTEP  development  jobs. 

D.  Implement  Database  Design 

This  task  will  be  performed  by  the  contractor,  and  it  will  be  performed 
concurrently  with  the  previous  task.  The  objective  of  this  task  is  to  write 
standardized  INGRES  command  statements  for  (1)  loading  CAPS  tables,  (2) 
changing/updating  CAPS  tables  and  (3)  retrieving  information  from  CAPS 
tables.  These  command  statements,  combined  with  the  description  of  the 
contents  and  organization  of  a  CAPS  database  provide  a  detailed  view  of  how  a 
RDBMS  can  address  specific  jobs  in  ARTEP  development. 

The  standardized  command  statements  will  be  developed,  to  a  large  extent, 
as  a  database  is  being  designed.  One  of  the  goals  of  database  design  is  to 
organize  information  into  tables  in  a  way  which  allows  information  to  be 
quickly  retrieved  in  a  manner  which  meets  the  functional  requirements  of  the 
system.  In  designing  the  database,  the  designer  must  therefore  consider 
information  retrieval.  That  is,  the  database  must  be  designed  in  a  way  which 
allows  short,  simple  commands  to  be  used. 

Examples  of  what  certain  types  of  INGRES  command  statements  might  look 
like  are  provided  and  briefly  explained  below. 
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create  coltask  (task  -  C50,  fa  refs  C255,  STX  -  C100) 


This  coaaand  creates  the  table  previously  shown  in  Figure  4.  The 
coaaand  tells  the  systea  to  create  a  table  called  "coltask"  and  to 
label  the  coluans  "task”,  "farefs"  and  stx".  In  addition,  the 
coaaand  indicates  the  aaxiaua  amount  of  space  allocated  for  each  row 
of  each  of  the  three  coluans  (e.g.,  the  title  of  a  collective  task 
can  be  up  to  fifty  characters  in  length,  and  up  to  255  characters  can 
be  used  to  list  all  of  the  tactical  references  which  apply  to  a 
particular  collective  task). 

o  retrieve  (c.  ctnaae)  where  c. farefs  “  "*  FM7-10  pg  36  par  4  *" 

This  coaaand  tells  the  systea  to  list  the  names  of  all  collective 
tasks  for  which  paragraph  4  or  page  36  of  FM  7-10  is  a  doctrinal 
reference.  (With  the  exception  of  the  specific  doctrinal  reference, 
this  command  is  applicable  to  any  atteapt  to  identify  collective 
tasks  supported  by  a  particular  doctrine  reference  .  .  .  within  any 
Army  school. ..given  the  table  design  in  Figure  4.) 

The  report  covering  this  task  will  Indicate  the  CAPS  functional 
specification  addressed  by  each  of  the  standardized  commands,  and  it  will  also 
provide  a  critique  of  the  overall  ability  of  the  database  design  and 
standardized  commands  to  meet  CAPS  functional  requirements.  It  is  important 
to  note  that  the  functional  requirements  considered  will  be  those  for  the 
working  CAPS  at  USAIS.  If  time  and  resources  permit,  database  additions  and 
commands  necessary  to  address  functional  requirements  unique  to  USAARMS  and 
USAICS  will  also  be  assessed.  The  results  of  these  assessments  would  be 
provided  to  ATSC-IMO. 

At  the  end  of  this  task,  a  decision  will  be  made  about  whether  the  CAPS 
database  appears  to  be  "user  friendly"  (i.e.,  can  be  applied  to  the  ARTEP 
development  process  using  short,  simple  commands).  This  decision  will  be 
based  on  the  review  of  the  sample  commands  contained  in  the  report.  The 
results  of  this  decision  will  have  a  profound  effect  on  the  work  required  to 
perform  the  subsequent  task. 

E.  Develop  Training  Plans 

The  CAPS  contractor  will  be  primarily  responsible  for  developing  training 
plans.  The  amount  of  work  required  to  develop  these  plans  depends,  to  a  large 
extent,  on  the  degree  to  which  the  CAPS  database  is  "user  friendly."  If  the 
database  is  exceptionally  "user  friendly,"  then  much  of  the  guidance  for 
applying  a  RDBMS  to  ARTEP  development  will  be  taken  from  existing  INGRES  RDBMS 
user  manuals.  If  the  database  is  moderately  "user  friendly,"  then  the 
contractor  will  probably  find  it  necessary  to  include  standardized  commands  in 
the  training  plan.  In  addition,  the  amount  of  training  required  to  gain  an 
adequate  level  of  proficiency  in  using  INGRES  RDBMS  may  increase.  If  the  CAPS 
database  is  not  "user  friendly,"  then  software  may  need  to  be  developed  to 
control  the  application  of  a  RDBMS  to  ARTEP  development. 

The  work  required  to  develop  training  plans  will  also  effect  what 
participants  in  the  CAPS  project  will  be  asked  or  required  to  do  when 
reviewing  the  draft  plans  for  clarity  and  adequacy.  At  present,  it  is 


expected  that  the  CAPS  database  will  be  either  exceptionally  or  moderately 
"user  friendly."  This  expectation  is  based  upon  the  simple  fact  that  all,  or 
nearly  all,  of  the  Information  within  a  CAPS  database  has  a  relationship  to 
the  same  variable  (i.e.,  the  titles  of  collective  tasks).  Briefly,  this 
pervasive  relationship  is  expected  to  reduce  the  number  of  tables  one  must 
deal  with  in  attempting  to  meet  a  particular  information  need  and  thus  keep 
the  database  commands  at  a  simple  level.  Perhaps  the  greatest  threat  to  the 
simplicity  of  the  CAPS  database  design  is  the  need  to  link  training 
requirements  at  one  echelon  with  those  at  another  echelon. 

Much  of  the  CAPS  training  is  Intended  to  be  embedded  in  the  system.  For 
example,  the  standardized  coaaands  to  be  developed  in  the  preceding  CAPS 
development  task  might  be  Included  in  a  RDBMS  table  and  linked  to  specific 
ARTEP  development  job  tasks.  The  first  column  of  the  table  might  list  job 
tasks  (e.g. ,  identifying  collective  tasks  supported  by  a  specific  doctrinal 
reference),  the  second  column  might  provide  the  standardized  conmand  for 
reorganizing  the  database  to  obtain  the  information  needed  to  perform  the 
task,  a  third  column  might  provide  "decision  aids"  where  required.  In  effect, 
the  listing  of  ARTEP  development  job  tasks  in  the  first  column  of  such  a  table 
serves  as  menu  of  ARTEP  preparation  guidance. 

According  to  DoD  Standard  7935  and  supplementary  Army  Technical  Bulletin 
18-111,  three  types  of  manuals  must  also  be  developed  to  support  the  use  of  an 
automated  system  as  described  below. 

o  A  "User's  Manual"  will  provide  information  for  the  user  of  a  CAPS 
work  station. 

o  A  "Computer  Operational  Manual”  will  provide  information  for  the 

manager  of  the  system  and  the  manager  of  the  database  to  use  in  day- 
to-day  operations. 

o  A  "Program  Maintenance  Manual"  will  provide  information  regarding 
future  system  maintenance. 

Schools  will  be  asked  to  review  these  manuals  and  comment  upon  their 
clarity  and  adequacy.  These  manuals  will  then  be  revised  by  the  contractor, 
as  necessary,  in  preparation  for  the  test  of  the  working  CAPS  within  USAIS. 

The  Program  Maintenance  Manual  might  be  of  special  interest  to  USAARMS  and 
USAICS,  because  one  key  aspect  of  future  maintenance  of  a  CAPS  involves 
expanding  the  database  to  serve  new  functions  (i.e.,  including  the  USAARMS  and 
USAICS  unique  functions  identified  in  the  first  CAPS  development  task).  At 
present  it  is  expected  that  the  functions  to  be  added  to  the  core  system  can 
be  anticipated,  and  effective  guidance  for  applying  functions  or  "types"  of 
functions  can  be  inserted  in  this  manual. 

F.  Prepare  a  Cost-Effectiveness  Evaluation  Plan 

ARI  will  have  the  primary  responsibility  for  preparing  a  cost-effective 
evaluation  plan.  This  plan  will  be  developed  to  address,  at  a  minimum,  the 
objectives  which  follow: 
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o  Assess  the  extent  to  which  the  working  CAPS  meets  the  functional 
requirements  identified  for  USAIS. 

o  Ascribe  failures  to  meet  functional  requirements  to  specific 

hardware,  software,  management/operations  plan  and/or  training  plan 
components  of  the  CAPS. 

o  Provide  cost  data  for  implementing/maintaining  the  CAPS  and  for 
modifying  the  CAPS  to  better  address  functional  requirements. 

The  evaluation  plan  is  intended  to  be  applied  during  an  extended  period  of 
CAPS  use.  This  period  of  use  will  begin  with  user  training  on  the  system  and 
continue  through  the  preparation  of  an  entire  AMTP  document.  By  using  an 
extended  testing  period  it  is  hoped  that  the  system  will  be  employed  under 
situations  which  adequately  reflect  the  variety  of  workloads  found  in  the 
typical  Army  School.  That  is,  the  system  will  be  evaluated  under  realistic 
conditions. 

A  draft  cost-effectiveness  evaluation  plan  will  be  staffed  for  school 
review,  and  an  In  Process  Review  (IPR)  will  be  conducted  to  discuss  and  refine 
the  draft.  It  is  expected  that  the  draft  plan  may  have  certain  gaps  which 
require  input  from  potential  CAPS  users.  For  example,  potential  system  users 
might  anticipate  certain  problems  (based  upon  their  familiarity  with  the 
environment  in  which  the  system  is  to  be  used),  and  it  is  necessary  to  make 
sure  that  the  evaluation  plan  is  sensitive  to  these  problems. 

G.  Load  Database  and  Conduct  Preliminary  Testing 

This  task  will  be  performed  by  the  contractor  at  the  contractor's 
facility.  The  goal  of  this  task  is  to  make  any  necessary  "fixes"  in  the 
working  CAPS  prior  to  moving  the  system  to  USAIS.  To  accomplish  this  task, 
the  contractor  will  load  the  database  with  the  user  POI  and  FEA  source 
materials  (provided  by  USAIS).  The  contractor  will  then  conduct  limited 
testing  of  all  hardware  and  software  components  of  the  system,  and  the 
contractor  will  prepare  a  demonstration  of  the  CAPS  for  project  participants. 

H.  Install  System  within  USAIS  and  Evaluate  During  Operational  Use 

During  this  phase  the  cost-effectiveness  evaluation  plan  will  be  executed 
by  ARI,  ATB  and  the  contractor.  This  phase  begins  with  the  installation  of 
the  working  CAPS  within  USAIS,  and  it  continues  through  the  development  of  a 
complete  AMTP  document  by  USAIS. 

It  is  important  to  consider  that  the  goal  of  this  task  is  to  refine  the 
CAPS  design  concept  rather  than  to  merely  test  this  concept.  On  the  spot 
"fixes"  will  be  made  by  the  contractor  and  tested  where  necessary  and  where 
feasible  (as  determined  by  ARI  and  ATB).  The  outcome  of  this  task  will  be  a 
report  which: 

o  provides  the  results  of  the  test  of  the  ability  of  the  working  CAPS 
to  meet  USAIS  function  requirements, 

o  describes  and  explains  the  need  for  any  changes  made  in  the  working 
CAPS  during  the  preliminary  or  formal  test  period, 


o 


provides  the  results  of  testing  any  modifications  made  during  the 
test  period, 


o  describes  and  explains  the  need  for  changes  in  the  system  which  could 
not  be  made  in  the  course  of  the  test  period. 
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Long-Term  CAPS  Refinements 


Future  refinements  in  the  CAPS  are  facilitated  by  (1)  employing  a  CAPS 
design  concept  which  is  modular  in  nature  and  (2)  ensuring  compatablllty  with 
other  Army  automated  systems  currently  under  development.  The  modular  nature 
of  the  CAPS  concept  makes  it  possible  to  modify,  delete  or  add  modules  to 
reflect  the  needs  of  individual  schools  and/or  future  changes  in  ARTEP 
design.  Compatibility  with  other  automated  systems  ensures  that  a  CAPS  can 
support  these  other  systems,  and  it  ensures  these  other  systems  can 
effectively  support  the  ARTEP  development  process. 

A.  Evolution  of  CAPS  as  an  Expert  System 

Perhaps  Artifical  Intelligence  (Al)  or"expert  systems"  represent  the 
current  pinnacle  of  computer  technology.  In  essence,  these  systems  mimic  the 
decision  processes  of  experts  within  a  particular  field.  For  example,  a  CAPS 
would  be  considered  to  be  an  expert  system  to  the  extent  that  it  mimics  the 
thought  processes  of  someone  who  has  finely  mastered  the  complexities  of  ARTEP 
development. 

To  an  extent,  the  CAPS  is  intended  to  be  an  expert  system  which  gets 
"smarter"  through  use.  For  example,  CAPS  will  initially  contain  "rules  of 
thumb"  and  standard  examples  for  writing  objective  performance  standards,  and 
these  standardized  examples  will  likely  be  in  terms  of  infantry  units.  A 
particular  school,  such  as  the  Armor  School,  would  have  the  option  and 
capability  to  replace  the  examples  in  the  existing  CAPS  database  with  examples 
tailored  in  terms  of  armor.  As  a  result,  the  CAPS  within  USAARMS  would  do  a 
better  job  of  mimicking  an  expert  at  developing  ARTEP  documents  for  armor 
units. 

The  tremendous  potential  for  increasing  the  level  of  expertise  of  a  CAPS 
might  also  be  illustrated  by  expanding  the  previous  example.  The  case  may  be 
that  the  initial  "rules  of  thumb"  for  writing  objective  standards  leave  much 
to  be  desired.  Through  the  TCMIS  which  links  the  CAPS  across  schools  (i.e., 
to  allow  sharing  of  databases),  one  school  might  review  the  databases  within 
other  schools  to  determine  whether  any  other  school  had  successfully  improved 
upon  the  "rules  of  thumb"  for  writing  standards.  If  so,  the  first  school 
might  replace  the  existing  ones  with  the  Improved  version  within  its  own  CAPS 
database.  In  this  way,  an  improvement  made  in  the  help  guidance  for  preparing 
A».TEP  documents  at  one  school  increases  the  extent  to  which  the  CAPS  at 
another  school  functions  as  an  expert  system.  This  example  illustrates  both 
(1)  how  the  CAPS  can  get  smarter  and,  (2)  the  importance  of  ensuring 
compatibility  between  CAPS  and  the  TCMIS-Training  Module. 

An  important  point  concerning  the  prototype  CAPS  is  that  certain  decision 
aids  contained  in  the  database  may  merely  serve  as  a  placeholder  for  improved 
information  developed  in  the  future.  That  is,  decisions  which  need  to  be 
addressed  by  aids,  have  been  identified,  and  draft  decision  aids,  regardless 
of  their  effectiveness,  can  serve  as  tools  in  designing  a  CAPS  database. 

B.  Interface  with  Other  Systems  Relevant  to  ARTEP  Development. 

The  CAPS  database  can  expand  to  incorporate  AKTEP-re levant  information 
from  other  systems  currently  under  development,  as  illustrated  in  Figure  6. 
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These  systeas,  which  :o  employ  the  INGRES  RDBMS,  are  brief described 
below. 

o  An  Integrated  Training  Management  System  (ITMS)  is  under  developaent 
by  the  Aray  Developaent  Eaployaent  Agency  (ADEA),  ATB,  the  Combined 
Aras  Center,  and  ARI.  This  systea  is  intended  to  support  unit 
training  aanageaent  for  all  units  within  a  division  through 
decentralized  work  stations.  Iaportant  data  froa  such  a  systea,  froa 
the  perspective  of  ARTEP  developers,  would  Include  the  frequency  with 
which  specific  aisslons,  collective  tasks.  Drills  and  STXs  are 
trained.  In  addition,  an  Electronic  Clipboard  under  developaent  by 
ARI  and  ATB  provides  input  for  the  ITMS  which  is  relevant  to  ARTEP 
developaent.  T&EOs  are  loaded  into  the  Clipboard  froa  the  ITMS,  and 
the  results  of  the  application  of  T&EO  standards  are  input  for  the 
ITMS  at  the  end  of  training/evaluation.  Information  froa  the 
Clipboard/ITMS  important  to  ARTEP  developers  would  Include  the 
identification  of  standards  with  a  high  frequency  of  "not  observed" 
(i.e. ,  suggesting  that  these  standards  may  require  revision). 


Center  is  under  developaent  within  the  ARI  Presidio  of  Monterey  Field 
Unit.  Analysis  of  the  data  within  this  systea  is  Intended  to  provide 
lessons  learned  froa  the  NTC  with  potential  applications  for  school 
doctrine  development  and  training  developaent. 

o  An  AMTP  Feedback  System  is  under  development  by  ATB  and  ARI  in 

cooperation  with  the  Army's  school  and  integrating  centers.  The 
purpose  of  this  system  is  to  gain  feedback  froa  units  regarding  AMTP 
design  features  through  a  series  of  iterative  surveys.  Such  surveys 
might  find,  for  example,  that  a  certain  AMTP  design  feature  is 
unacceptable  to  a  particular  user  population  (e.g. ,  Reserve  Component 
of  a  particular  type  of  unit).  In  the  long-term,  it  is  expected  that 
each  school  will  analyze  their  own  feedback  data  using  their  CAPS 
RDBMS.  In  the  near  term,  ARI/ATB  will  analyze  the  feedback  data 
using  INGRES  and  forward  significant  findings  to  appropriate 
integrating  centers  and  schools. 


APPENDIX  A 


MANAGEMENT  SUMMARY  OF  CAPS  DEVELOPMENT 


Given  the  need  for  prompt,  effective  application  of  coaputer  technology  to 
ARTEP  development,  it  is  important  that  the  review  process  for  all  CAPS 
contractor  products  be  carefully  orchestrated  to  avoid  delays.  Input  for 
revisions  of  draft  reports /manuals  is  to  be  provided  to  the  contractor  within 
15  days  of  the  delivery  of  the  draft  product.  Therefore,  these  rapid  response 
reviews  must  be  carefully  defined  in  terms  of  (1)  project  participants  taking 
part  in  these  reviews  and  (2)  major  areas  of  concern  of  each  participant. 

The  purpose  of  this  Appendix  is  to  provide  information  which  each  of  the 
various  points  of  contact  (POCs)  can  use  to  manage  their  organizations 
involvement  in  each  task  of  developing  a  working  CAPS.  This  information  will 
be  supplemented  with  a  contract  performance  plan  containing  project 
milestones,  after  the  CAPS  contract  is  awarded. 

The  following  pages  contain  the  types  of  management  information  described 
below  for  each  task  in  CAPS  development. 

o  draft  reports /manuals  to  be  reviewed 

o  specification  of  the  organizations  asked  to  review  each  draft 
document  prior  to  contractor  revision 

o  brief  description  of  the  primary  concerns  of  each  organization  in 
conducting  their  review 

Most  of  the  documents  to  be  produced  are  defined  by  AR  25-5  and  a  series 
of  Technical  Bulletins/Standards.  ARI  is  responsible  for  making  sure  that 
documents  are  in  compliance  with  these  requirements.  It  is  also  expected  that 
ATSC-IMO  will  also  be  interested  in  the  compliance  of  these  documents  with 
automation  requirements,  because  of  the  importance  of  ensuring  compatibility 
between  the  CAPS  and  other  components  of  the  TCMIS-Training  Module. 


* 


TASK  1:  REFINE/FINALIZE  CAPS  FUNCTIONAL  REQUIREMENTS 


DOCUMENTS 

FUNCTIONAL  DESCRIPTION 
DATA  REQUIREMENTS 


INTERESTS 

o  USAIS/ATB/ARI:  The  process  to  which  computer  technology  is  to  be  applied 
(AMTP/Drill  preparation)  is  itself  under  development.  There  is  a  need  to 

(1)  consider  how  to  best  refine  the  process  before  applying  automation  and 

(2)  make  sure  the  functional  requirements  fit  the  refined  process. 

o  ATSC-IMO;  IMO  is  concerned  with  effectively  linking  the  CAPS  to  other 
components  of  the  TCMIS-Training  Module.  IMO's  interests  include  such 
topics  as  (1)  desired  (possibly  long-term)  functions  which  are  contingent 
on  linking  the  CAPS  with  other  training  module  components  and  (2) 
differences  in  CAPS  functional  requirements  among  schools. 

o  USAARMS/USAICS:  These  schools  are  concerned  with  identifying  (1) 

functional  requirements  for  the  working  CAPS  which  would  be  Inappropriate 
for  their  schools  and  (2)  functional  requirements  they  would  want  to  add 
if  the  working  CAPS  were  being  developed  within  their  schools.  (NOTE: 

This  feedback  does  not  need  to  be  provided  in  time  for  contractor 
revision) . 


*An  IPR  will  be  conducted  and  all  project  paraticipants  will  be  invited  and 
asked  to  provide  feedback. 


task  2 :  PREPARE  ORGANIZATION.  MANAGEMENT  AND  OPERATING  PROCEDURES 


DOCUMENTS 

o  SYSTEMS /SUBSYSTEM  SPECIFICATIONS 
o  PROGRAM  SPECIFICATIONS 


WORKFLOW  ^ 

ALL  ] 

ARI 

T  CONTRACTOR! 

(DRAFT) 

USAIS 

(REVISE) 

USAARMS 

ARI 

I  MO 

USA1CS 

ATB 

[REVIEW) 

(REVIEW)  j 

I  HO 

INTERESTS 

o  ARI/USAIS  Make  sure  CAPS  procedures  are  thoroughly  described  aod  are 
coapatible  with  USAIS  procedures. 

o  IMP  Make  sure  specifications  support  compatibility  between  CAPS  and  other 
components  of  the  Training  Module. 

o  USAARMS/USAICS  Identify  procedures  inappropriate  for  application  in  their 
schools. 


TASK  3:  DESIGN  DATABASE  /  TASK  4:  IMPLEMENT  DATABASE  DESIGN 

DOCUMENTS 

DATABASE  SPECIFICATION 


i  contractor! 

(DRAFT) 


ARI/USAIS: 


no 

(REVIEW) 


WORKFLOW 


contractor! 

(REVISE) 


HuIlI 


INTERESTS 


Decide  which  functional  requireaents  are/are  not  addressed  by 
database  design. 


ALL: 


Estimates  of  the  extent  to  which  the  database  design  is  "user 
friendly. " 


TASK  5:  DEVELOP  TRAINING  PLANS 


DOCUMENTS 


o  USER'S  MANUAL 
o  COMPUTER  OPERATION  MANUAL 
o  PROGRAM  MAINTENANCE  MANUAL 
o  TRAINING  COURSE /CURRICULUM  OUTLINES 


j  ARI/ 

f  contractor"!  USAIS 

(DRAFTS)  ATB 


WORKFLOW 


f  CONTRACTp’r!  r  ALL  1 
(REVISE) 


INTERESTS 


o  ARI -USAIS /ATB:  Reviews  of  training  plans  and  manuals  will  be  conducted  to 

make  sure  that  these  materials  appear  to  be  complete  and  clearly 
written.  The  key  goal  of  this  review  Is  to  record  (1)  questions  the 
reviewers  have  before  reading  the  materials  which  are  not  effectively 
addressed  by  these  documents  and  (2)  questions  raised  during  the  review  of 
these  documents. 


1 


TASK  6:  PREPARE  A  COST-EFFECTIVENESS  EVALUATION  PLAN 


DOCUMENT 

ST STEM /COST-EFFECTIVENESS  PROGRAM  PLAN 


1  CONTRACTOR  | 
(DRAFT) 


[  ari/atb! 

(REVIEW) 


WORKFLOW 


> 


f  ARI /CONTRACTOR!  |~ALl| 
(REVISE) 


INTERESTS 


<>  ARI/ATB:  Making  sure  chat  Che  plan  (1)  effectively  addresses  all  CAPS 

functional  requirements  and  (2)  can  be  supported  by  available  ARI,  ATB  and 
contractor  personnel. 

o  USAIS:  Making  sure  that  the  plan  (1)  imposes  reasonable  requirements  on 
USAIS  and  (2)  is  sensitive  to  the  USAIS  working  environment. 

o  USAARMS/USAICS :  Making  sure  that  the  plan  is  sensitive  to  school  working 
environments. 


TASK  7:  LOAD  DATABASE  AND  CONDUCT  PRELIMINARY  TESTING 


Docutgyrs 

PREVIOUSLY  PREPARED  DOCUMENTS  MAY  BE  REVOSED 
AS  A  RESULT  OF  PRELIMINARY  TESTING  BY  ARI ,  ATB 
AND  THE  CONTRACTOR  AT  THE  CONTRACTOR'S  FACILITY. 


ARI /ATB/ 

CONTRACTOR 

CONTRACTOR 

(SUGGEST) 

(TESTING) 

NECESSARY 

REVISIONS) 

WORKFLOW  ^ 

ARI /ATB/ 

USAIS/IMO 
(APPROVE/ 

DISAPPROVE  CHANGES) 

SUGGESTIONS) 


contractor! 

(IMPLEMENT 


INTERESTS 


o  ARI /ATB;  Test  the  ability  of  the  working  CAPS  to  meet  those  functional 

requirements  which  can  meaningfully  be  tested  outside  a  school  context. 
Approve /disapprove  suggestions  for  system  "fixes"  depending  upon 
"feasibility. " 


o  AST C~ IMP :  Concerned  with  making  sure  that  suggested  changes  in 

hardware/software  do  not  reduce  compatibility  between  CAPS  and  other 
components. 

°  USAIS ;  Concerned  with  making  sure  that  system  "fixes"  are  compatible  with 
USAIS  procedures. 


A-7 


TASK  8:  INSTALL  SYSTEM  WITHIN  USAIS  AND  EVALUATE  PUKING  OPERATIONAL  USE 

DO CU EC  NTS 


o  PREVIOUSLY  PREPARED  DOCUMENTS  MAY  BE 
REVISED  IN  RESPONSE  TO  THE  FINDINCS  OF 
THE  COST-EFFECTIVENESS  EVALUATION. 

o  FINAL  REPORT  (INCLUDING  RESULTS  OF  EVALUATION) 


TESTING 


I  contractor! 

( IMPLEMENT 
CHANGES) 


WORKFLOW 


ARI/ATB 
CONTRACTOR 
(COLLECT  DATA) 


I  CONTRACTOR  1 
(SUGGEST 
NECESSARY 
REVISIONS) 


FINAL  REPORT/DOCUMENT  REVISION 


ICO  NT  RACTOin 
(DRAFT) 


QRp 

(REVIEW) 


1  CONTRACTOR-] 
(REVISE) 


ARI/ATB 
USAIS /I HO 
(APPROVE/ 
DISAPPROVE 
SUGGESTIONS 


I  all  ! 


INTERESTS 

o  ARI/ATB;  Approving/disapproving  changes  based  on  "feasibility.”  Da 
collection  and  analysis. 

°  USAIS ;  Using  systea  and  providing  feedback  regarding" 


overall  usefulness 


ease  of  use 


specific  probleas  in  application 


